home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19950726-19950929 / 000349_news@columbia.edu_Tue Sep 12 01:53:02 1995.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA06219
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Tue, 12 Sep 1995 12:27:22 -0400
  3. Received: by apakabar.cc.columbia.edu id AA19073
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Tue, 12 Sep 1995 12:26:50 -0400
  5. Path: news.columbia.edu!panix!news.mathworks.com!tank.news.pipex.net!pipex!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
  9. Message-Id: <1995Sep12.075302.61110@cc.usu.edu>
  10. Date: 12 Sep 95 07:53:02 MDT
  11. References: <42d2u9$edt@apakabar.cc.columbia.edu> <433mrn$49i@apakabar.cc.columbia.edu>
  12. Organization: Utah State University
  13. Lines: 84
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <433mrn$49i@apakabar.cc.columbia.edu>, chaiklin@merhaba.cc.columbia.edu (Seth Chaiklin) writes:
  17. > In article <2979@sun3.ipswitch.com>, Dan Lanciani <ddl@harvard.edu> wrote:
  18. > 
  19. > [stuff deleted about how a MSK machine would lose control of the
  20. >  terminal output after about 10 minutes and the ARP cache on a Linux
  21. > (1.2.8) machine would lose the hardware address of the MSK machine.  ]
  22. > 
  23. >>You'd need a network trace to be sure, but this suggests that kermit
  24. >>isn't responding to ARPs in its current state.
  25. > 
  26. > I have traceroute and netstat (and maybe some others) on the Linux box.
  27. > It was mentioned that this could be helpful, but I do not know what I should
  28. > do or what I should look for.
  29. > 
  30. >>There are at least two additional experiments that might shed light on
  31. >>the situation.
  32. >>First, while in the bad state, try to ping it from another machine that
  33. >>has never been involved with the connection at all.  This should tell
  34. >>you whether kermit is willing to respond to anybody's ARP at this point.
  35. > 
  36. > I did try this, and the MSK machine responded to the ping, so there was no
  37. > need to try the second test.  
  38. > 
  39. > I also tried to ping from the Linux box, but there was no response.
  40. > However, if I handloaded the Hardware address of the ethernet
  41. > card on the MSK machine, then I could get a ping response.
  42. > 
  43. > However, this handloading technique does not always result in control being
  44. > returned to the MSK machine, as I once reported.
  45. > 
  46. > Meanwhile, some more information.  After the MSK machine would not
  47. > respond (this again means, no output on the screen.  It is still possible
  48. > to shell out to DOS, issue commands to the Linux box (as confirmed with a
  49. > 'w' command from the console) etc., etc.), I tried to telnet to the same 
  50. > Linux machine as well as other machines.  I got the error message:  
  51. > Unable to ARP resolve gateway
  52. > 
  53. > This was when I tried to ping from the Linux machine (with no response).
  54.  
  55.     This rather clearly indicates that the Linux TCP/IP stack has real
  56. problems with its ARP cache and destination MAC address handling.
  57.  
  58. > I tried another experiment.  I logged in from the MSK machine, then immediately
  59. > deleted the entry from the Linux ARP cache.  The output stopped, as other
  60. > times.  It was still possible to telnet to other machines, but now it was 
  61. > impossible to telnet to the Linux machine, no error message or anything, just 
  62. > a return to the Kermit prompt.
  63.  
  64.     Ditto.
  65.  
  66. > Finally, I hand-entered the hw address for the MSK machine, and now I have 
  67. > tried two or three times to let the MSK machine sit for for 30-60 minutes,
  68. > and I have not been able to reproduce the problem.  It sounds like I 
  69. > should just try to load the addresses for these cards, maybe even as a
  70. > cron job...but I would still like to try to understand what is going wrong.
  71. >   
  72. > I noticed in a recent message that there was an updated version of Kermit.
  73. > I use a version from 18 Jan 95.  Could this also be a possible source of the
  74. > problem?
  75.  
  76.     Not that I can deduce.
  77.  
  78. > So I put a copy of 21 May 1995 onto the MSK machine.  Tried to connect to 
  79. > the Linux box and got:  Unable to ARP resolve xxx.yyy.xxx.zzz
  80. > However, I was able to telnet to other machines.
  81. > 
  82. > Aaarrgh!  I am really interested in solving this problem because we 
  83. > would like to use 8-bit characters, and other telnet programs do not 
  84. > behave as well as Kermit about this.
  85.  
  86.     How about talking to the Linux News groups for hints. You are not
  87. the only person to report such problems.
  88.  
  89. > Also, when these "freeze-ups" do happen, it does not seem proper that
  90. > MS-Kermit should lockup on "exit" or "hangup" requiring a power-down
  91. > to restart the machine.   I just wanted to re-emphasize that point.
  92.  
  93.     If MSK sends a TCP segment which requires an acknowledgment from
  94. the other end then it must wait and wait for it, and finally give up after
  95. a long interval. The process of tearing down a connection does the same
  96. (tries a proper FIN close, then if necessary sends an RST and bails out,
  97. but the FIN close has time delays. Unack'd data requires waiting, and
  98. FIN, and waiting...).
  99.     Joe D.